# Using an Audit table

When defining a replication task, you can choose to store changes to all tables in a single Audit table (located in the target endpoint). The changes can then be pushed from a single stream to any queue (JMS for example).

The following table describes the structure of the Audit table.

Audit table structure

| Column Name | Type | Description |
| --- | --- | --- |
| `task_name` | varchar (128) | The name of the replication task. |
| `change_seq` | bigint | A monotonically increasing change sequencer that is common to all change tables of a task. The change sequence has the following format:<br><br>YYYYMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx<br><br>Where:<br><br><ul> <li>YYYY is the four-digit year (such as 2012)</li> <li>MM is the two-digit month (range from 01-12)</li> <li> <p>DD is the two-digit day (range from 01-31)</p> </li> <li>HH is the hour in the day (range from 00-23)</li> <li>mm is the minute in the hour (range from 00-59)</li> <li>SS is the second in the minute (range from 00-59)</li> <li>hh is the hundredth of the second (range from 00-99)</li> <li>xxxxxxxxxxxxxxxxxxx is a 19-digit, zero prefixed change number (global per task)</li> </ul><br><br>The time part usually refers to the commit time of the transaction that includes the change record. Replicate contains logic that maintains the monotonicity of the sequence number so modifying or adjusting the endpoint time may result in multiple changes to seem that they are within the same timestamp but with increasing change number.<br><br>The xxx...xxx is usually the internal change number from the data record except that for BEFORE-IMAGE records it is the same as the change number of the matching UPDATE record (for example, if the change number of BEFORE-IMAGE is 1000 and that of the UPDATE is 1001, then both have 1001). This allows a simple left-outer-join between the table and itself where on the left we scan until the point in time but filter out `operation=before-image`, and on the right we join on the same `change_seq` with the `change_oper` being 'B' . |
| `change_oper` | varchar (1) | The operation type. This can be one of the following:<br><br>`I`: INSERT<br><br>`D`: DELETE<br><br>`U`: UPDATE<br><br>`B`: Before Image |
| `stream_position` | varchar (128) | The source CDC stream position. |
| `schema_name` | nvarchar (128) | The name of the source table schema. |
| `table_name` | nvarchar | The name of the source table. |
| `operation` | varchar (12) | The operation associated with the change record. It can be one of the following:<br><br><ul> <li>INSERT</li> <li>UPDATE</li> <li>DELETE</li> <li>BEFOREIMAGE</li> </ul> |
| `transaction_id` | varchar (32) | The ID of the transaction that the change record belongs to.<br><br>The value is a hex-string of the 128-bit transaction ID. |
| `timestamp` | timestamp | The original change timestamp (the value may be approximate). |
| `change_record`<br><br>Information note<br><br>The data is stored in JSON format. | nclob | The new data.<br><br>Information note<br><br>LOB columns with unlimited size are not supported in the `change_record` field. The other fields will be recorded but the LOB will have a NULL value. |
| `bu_change_record`<br><br>Information note<br><br>The data is stored in JSON format. | nclob | The data before the update.<br><br>Information note<br><br>LOB columns with unlimited size are not supported in the `bu_change_record` field. The other fields will be recorded but the LOB will have a NULL value. |
| Partition start |  | Partition name, partition start time (UTC), and estimated partition end time (UTC) |
| Partition end |  | Partition name, partition start time (UTC), partition end time (UTC), and a list of changed tables (identified by table name and schema name). |

For more information on storing changes in an audit table, see [Store Changes Settings](https://help.qlik.com/en-US/replicate/May2026/Content/Global_Common/Content/SharedEMReplicate/Customize%20Tasks/store_changes_settings.htm).